Correctness and Completeness of CASE Tools in Reverse EngineeringSource Code into UML Model

This paper focuses on Computer-aided Software Engineering (CASE) tools that offer functionality for reverse engineering into Unified Modeling Language (UML) models. Such tools can be used for design recovery or round-trip engineering. For these purposes, the quality and correctness of the reverse engineering capability of these tools is of key importance: Do the tools completely reconstruct the UML diagrams? Are the reverse engineering results correct? What kind of information is presented in the result? Based on these questions, we compare eight UML CASE tools (six commercial tools and two open source tools). We evaluate i) the types of inputs that these tools can handle, ii) the types of diagrams that can be reconstructed, iii) the quality of resulting diagrams

An automated approach for classifying reverse-engineered and forward-engineered UML class diagrams

UML Class diagrams are commonly used to describe the designs of systems. Such designs can be used to guide the construction of software. In practice, we have identified two main types of using UML: i) FwCD refers to diagrams are hand-made as part of the forward-looking development process; ii) RECD refers to those diagrams that are reverse engineered from the source code; Recently, empirical studies in Software Engineering have started looking at open source projects. This enables the automated extraction and analysis of large sets of project-data. For researching the effects of UML modeling in open source projects, we need a way to automatically determine the way in which UML used in such projects. For this, we propose an automated classifier for deciding whether a diagram is an FwCD or an RECD. We present the construction of such a classifier by means of (supervised) machine learning algorithms. As part of its construction, we analyse which features are useful in classifying FwCD and RECD. By comparing different machine learning algorithms, we find that the Random Forest algorithm is the most suitable algorithm for our purpose. We evaluate the performance of the classifier on a test set of 999 class diagrams obtained from open source projects

Interactive User-Oriented Views for Better Understanding Software Systems

Abstract Understanding software artefacts is a crucial task for people who want to participate in any software development process. However, because of the large amount of detailed and scattered information in software artefacts, understanding them is usually time-consuming and vulnerable to human errors and subjectivities. A system that aids practitioners to investigate understanding about software artefacts could reduce the vulnerabilities and speed up software development/maintenance process. Our research focuses on building a comprehensive view of software system in order for developers to achieve the two goals: (i) to save the time spending on searching and navigating on source code; and (ii) to gain better understanding about software artefacts regarding to domain-specific tasks. To achieve these goals, we propose an emprical approach in which the visualisation and the generation of high-level design and architectural views from source code and design documentations have been played central roles. The research is on-going and could potentially be extended to di↵erent software artefacts (such as requirements, use-cases, test-cases, revision logs)

Are Forward Designed or Reverse-Engineered UML Diagrams More Helpful for Code Maintenance?: A Controlled Experiment

Context: UML has been the de facto standard notation for modeling object-oriented software systems since its appearance in 1997. UML diagrams are important for maintainers of a system, especially when the software was developed by a different team. These diagrams of the system are not always available, however, and are commonly recovered using Reverse Engineering (RE) techniques. When obtained through RE, UML diagrams have a high level of detail as compared to those developed in the forward design activity. Method: In this paper we report on a comparison of the attitude and performance of maintainers when using these two kinds of diagrams during the maintenance of source code. Our findings were obtained by carrying out a controlled experiment with 40 students of a Master’s degree in Computer Science. Results: The results show a preference for forward design diagrams but do not display significant differences in task performance. The post-experiment survey results have led us to conclude that the subjects did not consider RE diagrams helpful; they found them difficult to understand, particularly the sequence diagrams. In the case of forward design diagrams, subjects considered sequence diagrams as useful, but they did not really employ them. Conclusions: Based on our findings, as regards performance of maintainers, there are no objective results which favor the use of one of these types of diagram in particular, i.e., UML diagrams which come from forwards design, on the one hand, and diagrams obtained from RE, on the other. Subjective opinions do, however, lead us to recommend the use of diagrams created during design. Nevertheless, we realize that the results should be considered as preliminary ones; further replications of this experiment are planned, using students and professionals, the aim being to obtain more conclusive results.Ministerio de Economía y Competitividad TIN2012-37493-C03-0

Evaluating the layout quality of UML class diagrams using machine learning

UML is the de facto standard notation for graphically representing software. UML diagrams are used in the analysis, construction, and maintenance of software systems. Mostly, UML diagrams capture an abstract view of a (piece of a) software system. A key purpose of UML diagrams is to share knowledge about the system among developers. The quality of the layout of UML diagrams plays a crucial role in their comprehension. In this paper, we present an automated method for evaluating the layout quality of UML class diagrams. We use machine learning based on features extracted from the class diagram images using image processing. Such an automated evaluator has several uses: (1) From an industrial perspective, this tool could be used for automated quality assurance for class diagrams (e.g., as part of a quality monitor integrated into a DevOps toolchain). For example, automated feedback can be generated once a UML diagram is checked in the project repository. (2) In an educational setting, the evaluator can grade the layout aspect of student assignments in courses on software modeling, analysis, and design. (3) In the field of algorithm design for graph layouts, our evaluator can assess the layouts generated by such algorithms. In this way, this evaluator opens up the road for using machine learning to learn good layouting algorithms. Approach.: We use machine learning techniques to build (linear) regression models based on features extracted from the class diagram images using image processing. As ground truth, we use a dataset of 600+ UML Class Diagrams for which experts manually label the quality of the layout. Contributions.: This paper makes the following contributions: (1) We show the feasibility of the automatic evaluation of the layout quality of UML class diagrams. (2) We analyze which features of UML class diagrams are most strongly related to the quality of their layout. (3) We evaluate the performance of our layout evaluator. (4) We offer a dataset of labeled UML class diagrams. In this dataset, we supply for every diagram the following information: (a) a manually established ground truth of the quality of the layout, (b) an automatically established value for the layout-quality of the diagram (produced by our classifier), and (c) the values of key features of the layout of the diagram (obtained by image processing). This dataset can be used for replication of our study and others to build on and improve on this work. Editor\u27s note: Open Science material was validated by the Journal of Systems and Software Open Science Board

Software engineering whispers: The effect of textual vs. graphical software design descriptions on software design communication

Context:\ua0Software\ua0engineering\ua0is a social and collaborative activity. Communicating and sharing knowledge between\ua0software\ua0developers requires much effort. Hence, the quality of\ua0communication\ua0plays an important role in influencing project success. To better understand the\ua0effect\ua0of\ua0communication\ua0on project success, more in-depth empirical studies investigating this phenomenon are needed. Objective: We investigate the\ua0effect\ua0of using a\ua0graphical\ua0versus\ua0textual\ua0design\ua0description\ua0on co-located\ua0software\ua0design\ua0communication. Method: Therefore, we conducted a family of experiments involving a mix of 240\ua0software\ua0engineering\ua0students from four universities. We examined how different\ua0design\ua0representations (i.e.,\ua0graphical\ua0vs.\ua0textual) affect the ability to Explain, Understand, Recall, and Actively Communicate knowledge. Results: We found that the\ua0graphical\ua0design\ua0description\ua0is better than the\ua0textual\ua0in promoting Active Discussion between developers and improving the Recall of\ua0design\ua0details. Furthermore, compared to its unaltered version, a well-organized and motivated\ua0textual\ua0design\ua0description–that is used for the same amount of time–enhances the recall of\ua0design\ua0details and increases the amount of active discussions at the cost of reducing the perceived quality of explaining